Uvidíme, snad odpoví... V opačném případě by se to dalo řešit přes API a google maps... ale zatím nemám tuchu, kdo by měl náladu se do toho pustit.

Myslim ze je dulezite ze data jdou do RF.
S Hessu jsem uz vminulosti komunikoval take a zdal se mi pristupny k diskuzim, takze verim ze se s nim neco vymysli.
Ovsem vlastni zobrazeni objektu z COM-10 na strankach aprs.cz by nemuselo byt komplikovane, zkusim to nadhodit svemu dvornimu web-mechanikovi :).

Rozhodli jsme se s Honzou opet o kontaktovani Hessu a pokusit se nejak vyresit zobrazovani objektu na aprs.fi
Zde je jeho odpoved:
Hi,

On Thu, 1 Mar 2012, Libor Augustin wrote:

The last mentioned, the Lighting Detection&Reporting system is the main issue as i have the
informations from Honza.
Every new lighting strike reported by the system is expressed by the new object, the object name is
composed of current date and time, ie. STR260946 (name prefix,day,hour,minute). Because of that naming,
there is thousands of individual, short lived objects that are stored in database now. Correct me here
if iam wrong.

That's right.

1. we keep the current naming and include the special tag at the end of the object comment. This tag
will tells your system to not store such objects to prevent the overloading or save just for a few
hours to display it. The tag will be something which we decide together, something you prefer to be and
something you can then remove from the actual comment to not display it in the station informations
(same as PHG or DAO).

I get quite a lot of requests for special features needed by individual users or small groups of users worldwide. Unfortunately I do not have enough time to do everything, so I try to concentrate implementing things which benefit large groups of users (on global scale!) so that the time is well spent and benefits as many users as possible. So, I won't do some special tag hack only for you guys - it would need to be a real APRS standard extension which everyone can implement and utilize for other general use cases. It would need to be discussed on the APRSSIG with other implementors.

2. another idea is to removing any APRS object which transmitted just and only ONE beacon in a life
after defined duration. Lets say 24 hours or several days (week?). In this case, ANY object or station
in a world, will not be stored if some of the following examples comes true:
- station accidentaly transmitted beacon (weird saying but could happen)
- short lived objects like the lighting strikes
- there is a beacon, which is not real station and this could happen, when some TNCs are faulty or
accidentaly decode the packet in a wrong way. The example is here: http://aprs.fi/?call=a%2FCZ3-3. Ii
is a non existing station, the real station at this QTH is http://aprs.fi/?call=a%2FOK0BCA-1&_s=mb.
CZ3-3 is state routing path (SSn-N).
- there might be even more examples ...
The second idea is more complex solution, not requiring user's attention and everything happens
automaticaly.

Good idea! aprs.fi already does exactly this (has been doing for a couple years), but it isn't effective enough - a lot of crap comes in more than once, including the lightning strikes. Many APRS packet corruptions are systematic - your example has had 12 different positions stored in the database over time (see http://aprs.fi/info/a/CZ3-3). For the strikes: "STR260946 (name prefix,day,hour,minute)" - a proper thunderstorm will have multiple strikes per minute at different locations, making the object jump around. And there are thunderstorms around the world all the time, making such naming scheme fall over quickly.

aprs.fi, or the APRS-IS in general, does not have a design which would really support worldwide lightning strike information distribution. With some hacks like (1) you might be able to do it for your country, but if a few others would try to do it at the same time, it would break. I would not like to see one object generator doing something that others shouldn't take an example of.

3.

I would recommend you to push lightning information to a network designed to transmit it (I think www.blitzortung.org is a popular distributed lightning receiver network), and keep it there. With some nice KML overlay magic we can then render the information on top of the aprs.fi map without actually polluting the APRS-IS or aprs.fi's database. Here's how you can tell aprs.fi to load a kml file, residing on another web server, on top of the map:

http://aprs.fi/?lat=38.8720&lng=-77.0570&z=15&kml=http%3A%2F%2Fhe.fi%2Fmisc%2Fpentagon.kml

If the lightning data is presented in KML somewhere, I could support a feature to have things like that conveniently listed in the "Overlays" drop-down menu in the top right corner of the real-time map. The 'Weather' item there from NOAA isn't good, some better items would be welcome.

- Hessu

Z cehoz plyne, ze neni naklonen nejake "individualni" praci a implementaci systemu na vyrazeni nekterych stanic, nebo objektu pomoci nejakeho specialniho oznaceni v textu.
Tudiz od nej zrejme zadne reseni cekat nemuzeme a musime si pomoct nejak sami.

Proto vyvstava otazka co s tim.
Nabizi se jedno reseni, ktere lze pojmout dvemi zpusoby.
- Vysilat blesky i nadale pod znackou OK1COM-10 a vyuzit tak stavajiciho filtru na strane aprs.fi. Tim umoznime i nadale jejich vysilani na RF, avsak nebudou zobrazovany na aprs.fi. A dale presunuti istatnich objektu (METAR, CHMI, TA, SPA ...) na jinou znacku, respektive jine SSID. Toto reseni bude vyzadovat upravu nastaveni igate tak, aby vysilaly objekty z jine znacky (SSID).
- Ponechat vysilani objektu pod OK1COM-10 a presunout blesky na jinou znacku (SSID). V tomto pripade budeme muset Hessu pozadat o nastaveni filtru na novou znacku kde budou nove jen blesky a odstraneni filtru pro OK1COM-10 tak, aby se ostatni objekty (METAR, CHMI, TA, SPA ...) zacaly zobrazovat. Toto reseni bude opet vyzadovat upravu nastaveni igate tak, aby vysilaly blesky z nove znacky (SSID).

Myslim ze Honza se ktomu jeste nejak vyjadri a upresni me.

A nebo na to jít variantou les. t.j. aby se vlk nažral a kozy zůstaly na svém místě.

Což takhle se zkusit zamyslet na tím, že by se "recyklovaly" názvy objektů blesků. Schválně teď nebudu zmiňovat žádná konkrétní čísla, ta se dají najít v historii nebo upravit dle praxe.

V podstatě by šlo o to, že by názvů objektů blesků byl omezený počet. Např.
OK_STR1 - OK_STR 400 (pro poláky kdyby měli chuť a přidali by se tak SP_STR1 - SP_STR400) COM-10 by při každém vyslání nového blesku inkrementoval čítač o 1. Pro Hessu by to mohlo být vyhovující, protože by mu databáze nenabývala nekontrolovaně o hromady objektů, na druhou stranu myslím, že 400 str na jednu bouřku (či den) by mělo ve většině případů stačit.

Pak je možnost opravdu vyhradit jednu CALL která by byla zablokovaná na aprs.fi, po rádiu by to šlo normálně, vidět by to bylo na blitzotnung.net nebo http://www.openaprs.net/ měl li by někdo zájem na to koukat z internetu.

To je dobej napad!!
Mozna by stacilo i 100. Protoze vysilani blesku je omezeno na 1 za minutu (kvuli stavajicimu nazvu a prehlceni site). 100=100minut a 100minut stare blesky jsou uz stare. Nebo by se pak dalo snizit cetnost na 30sekund a mohlo by jich byt 200.
Polaky bych neresil.